The 3GPP standard 25.331 specifies the radio resource control (RRC) protocol for the radio interface between a wireless transmit/receive unit (WTRU) and a UMTS terrestrial radio access network (UTRAN). Section 8.6 of standard 25.331 describes the rules that the WTRU must follow for validating downlink peer messages received from the UTRAN. Included in this section are rules regarding transport channel information elements (IEs).
Specifically, the standard states in Section 8.6.5.2 that if the IE “Transport format combination set” is not included and either (1) if no transport format combination set is stored in the WTRU; or (2) if transport channels are added or removed in the message; or (3) if any transport channel is reconfigured in the message such that the size of the transport format set is changed, then the WTRU shall set the variable INVALID_CONFIGURATION to TRUE.
This means that if the any of the above conditions are met, the WTRU should reject the peer message. The rule does not take additional information into account, such as the type of transport channel being modified, the configured RRC state of the WTRU, etc.
The two basic operational modes of a WTRU are “Idle” and “Connected” modes. The Connected mode is further divided into several RRC states (i.e., a CELL_DCH state, a CELL_FACH state, a CELL_PCH state, and a URA_PCH state), which define the kind of channels that the WTRU is using. In the CELL_DCH state, dedicated channels are allocated to the WTRU. In the CELL_FACH state, no dedicated channel is allocated for the WTRU but the WTRU uses common channels which are shared by all WTRUs. While in the CELL_FACH state, the WTRU may receive (and must retain) certain information regarding dedicated channels. This information may then be used by the WTRU if the WTRU is directed by UTRAN to transition into the CELL_DCH state.
During an interoperability test session, a WTRU under test failed several connection attempts. Analysis showed that the WTRU was rejecting the network's RRC connection setup message because it broke the validation rule. Specifically, the message was directing the WTRU to the CELL_FACH state and was adding a dedicated transport channel, but was not including a transport format combination set (TFCS). The problem was that the validation rule was indeed broken as written. Based on this test result, the implementation of the validation rule could benefit from being more flexible.
Network operators may be tempted to read this rule liberally, thinking that the rule should only apply to transport channel elements that the WTRU will use in its immediately configured RRC state. The temptation (and perhaps confusion) is reinforced by the current ASN. 1 message syntax which requires networks to add dedicated transport channels to all WTRUs upon RRC connection setup, even those being configured for the CELL_FACH state. However, simply delaying an application of the rule until such time as the channels will be used (i.e., when the WTRU is configured for CELL_DCH) will not suffice since the rule is transaction-based. By applying the rule as it is written, the WTRU may reject an operable configuration (such as in the case described above). But by delaying the application of the rule, as the following example shows, the WTRU may accept an inoperable configuration, which is arguably worse.
For example, consider a WTRU that is operating in a CELL_DCH state. A UTRAN sends a message to the WTRU directing it to a CELL_FACH state and removing a transport channel, but not including a new TFCS. The WTRU accepts this message because the transport channels will not be used in the CELL_FACH state. A UTRAN sends a message to the WTRU directing it to a CELL_DCH state, including neither new transport channel information nor a new TFCS. The WTRU accepts this message because it does not break the validation rule. However, the WTRU will not be able to operate in the CELL_DCH state because it lacks the appropriate transport channel information or TFCS.